JavaScript Promise迷你书（中文版）

我们先来看一看下面的示例代码。

asyncFunction 这个函数会返回promise对象， 对于这个promise对象，我们调用它的 then 方法来设置resolve后的回调函数， catch 方法来设置发生错误时的回调函数。

该promise对象会在setTimeout之后的16ms时被resolve, 这时 then 的回调函数会被调用，并输出 'Async Hello world' 。

在这种情况下 catch 的回调函数并不会被执行（因为promise返回了resolve）， 不过如果运行环境没有提供 setTimeout 函数的话，那么上面代码在执行中就会产生异常，在 catch 中设置的回调函数就会被执行。

当然，像promise.then(onFulfilled, onRejected) 的方法声明一样， 如果不使用catch 方法只使用 then方法的话，如下所示的代码也能完成相同的工作。

我们已经大概了解了Promise的处理流程，接下来让我们来稍微整理一下Promise的状态。

用new Promise 实例化的promise对象有以下三个状态。

关于上面这三种状态的读法，其中 左侧为在 ES6 Promises 规范中定义的术语， 而右侧则是在 Promises/A+ 中描述状态的术语。

基本上状态在代码中是不会涉及到的，所以名称也无需太在意。 在这本书中，我们会基于 Promises/A+ 中 Pending 、 Fulfilled 、 Rejected 的状态名称进行讲述。

到此在本文中我们已经介绍了promise所有的三种状态。

promise对象的状态，从Pending转换为Fulfilled或Rejected之后， 这个promise对象的状态就不会再发生任何变化。

也就是说，Promise与Event等不同，在.then 后执行的函数可以肯定地说只会被调用一次。

另外，Fulfilled和Rejected这两个中的任一状态都可以表示为Settled(不变的)。

从Pending和Settled的对称关系来看，Promise状态的种类/迁移是非常简单易懂的。

当promise的对象状态发生变化时，用.then 来定义只会被调用一次的函数。

创建promise对象的流程如下所示。

按这个流程我们来实际编写下promise代码吧。

我们的任务是用Promise来通过异步处理方式来获取XMLHttpRequest(XHR)的数据。

让我们在实际中使用一下刚才创建的返回promise对象的函数

如Promises Overview 中做的简单介绍一样，promise对象拥有几个实例方法， 我们使用这些实例方法来为promise对象创建依赖于promise的具体状态、并且只会被执行一次的回调函数。

为promise对象添加处理方法主要有以下两种

首先，我们来尝试一下为 getURL 通信成功并取到值时添加的处理函数。

此时所谓的 通信成功 ， 指的就是在被resolve后， promise对象变为FulFilled状态 。

被resolve后的处理，可以在.then 方法中传入想要调用的函数。

getURL函数 中的 resolve(req.responseText); 会将promise对象变为resolve（Fulfilled）状态， 同时使用其值调用 onFulfilled 函数。

不过目前我们还没有对其中可能发生的错误做任何处理， 接下来，我们就来为 getURL 函数添加发生错误时的异常处理。

此时 发生错误 ， 指的也就是reject后 promise对象变为Rejected状态 。

被reject后的处理，可以在.then 的第二个参数 或者是在 .catch 方法中设置想要调用的函数。

把下面reject时的处理加入到刚才的代码，如下所示。

在getURL 的处理中发生任何异常，或者被明确reject的情况下， 该异常原因（Error对象）会作为 .catch 方法的参数被调用。

其实 .catch只是 promise.then(undefined, onRejected) 的别名而已， 如下代码也可以完成同样的功能。

一般说来，使用.catch来将resolve和reject处理分开来写是比较推荐的做法， 这两者的区别会在then和catch的区别中再做详细介绍。

静态方法Promise.resolve(value) 可以认为是 new Promise() 方法的快捷方式。

比如 Promise.resolve(42); 可以认为是以下代码的语法糖。

在这段代码中的 resolve(42); 会让这个promise对象立即进入确定（即resolved）状态，并将 42 传递给后面then里所指定的 onFulfilled 函数。

方法 Promise.resolve(value); 的返回值也是一个promise对象，所以我们可以像下面那样接着对其返回值进行 .then 调用。

Promise.resolve作为 new Promise() 的快捷方式，在进行promise对象的初始化或者编写测试代码的时候都非常方便。

Promise.resolve 方法另一个作用就是将 thenable 对象转换为promise对象。

ES6 Promises里提到了Thenable这个概念，简单来说它就是一个非常类似promise的东西。

就像我们有时称具有 .length 方法的非数组对象为Array like一样，thenable指的是一个具有 .then 方法的对象。

这种将thenable对象转换为promise对象的机制要求thenable对象所拥有的 then 方法应该和Promise所拥有的 then 方法具有同样的功能和处理过程，在将thenable对象转换为promise对象的时候，还会巧妙的利用thenable对象原来具有的 then 方法。

到底什么样的对象能算是thenable的呢，最简单的例子就是 jQuery.ajax()，它的返回值就是thenable的。

因为jQuery.ajax() 的返回值是 jqXHR Object 对象，这个对象具有 .then 方法。

这个thenable的对象可以使用 Promise.resolve 来转换为一个promise对象。

变成了promise对象的话，就能直接使用 then 或者 catch 等这些在 ES6 Promises里定义的方法了。

Promise.resolve 只使用了共通的方法 then ，提供了在不同的类库之间进行promise对象互相转换的功能。

这种转换为thenable的功能在之前是通过使用 Promise.cast 来完成的，从它的名字我们也不难想象它的功能是什么。

除了在编写使用Promise的类库等软件时需要对Thenable有所了解之外，通常作为end-user使用的时候，我们可能不会用到此功能。

简单总结一下 Promise.resolve 方法的话，可以认为它的作用就是将传递给它的参数填充（Fulfilled）到promise对象后并返回这个promise对象。

此外，Promise的很多处理内部也是使用了 Promise.resolve 算法将值转换为promise对象后再进行处理的。

其实在Promise之外也存在这个问题，这里我们以一般的使用情况来考虑此问题。

这个问题的本质是接收回调函数的函数，会根据具体的执行情况，可以选择是以同步还是异步的方式对回调函数进行调用。

下面我们以 onReady(fn) 为例进行说明，这个函数会接收一个回调函数进行处理。

mixed-onready.js会根据执行时DOM是否已经装载完毕来决定是对回调函数进行同步调用还是异步调用。

因此，如果这段代码在源文件中出现的位置不同，在控制台上打印的log消息顺序也会不同。

为了解决这个问题，我们可以选择统一使用异步调用的方式。

关于这个问题，在 Effective JavaScript 的 第67项 不要对异步回调函数进行同步调用 中也有详细介绍。

前面我们看到的 promise.then 也属于此类，为了避免上述中同时使用同步、异步调用可能引起的混乱问题，Promise在规范上规定 Promise只能使用异步调用方式 。

最后，如果将上面的 onReady 函数用Promise重写的话，代码如下面所示。

由于Promise保证了每次调用都是以异步方式进行的，所以我们在实际编码中不需要调用 setTimeout 来自己实现异步调用。

在第一章 promise chain 里我们看到了一个很简单的 then → catch 的例子，如果我们将方法链的长度变得更长的话，那在每个promise对象中注册的onFulfilled和onRejected将会怎样执行呢？

我们先来看看下面这样的promise chain。

上面代码中的promise chain的执行流程，如果用一张图来描述一下的话，像下面的图那样。

在 上述代码 中，我们没有为 then 方法指定第二个参数(onRejected)，也可以像下面这样来理解。

再看一下 上面的流程图 的话，我们会发现 Task A 和 Task B 都有指向 onRejected 的线出来。

这些线的意思是在 Task A 或 Task B 的处理中，在下面的情况下就会调用 onRejected 方法。

在 第一章 中我们已经看到，Promise中的处理习惯上都会采用 try-catch 的风格，当发生异常的时候，会被 catch 捕获并被由在此函数注册的回调函数进行错误处理。

另一种异常处理策略是通过 返回一个Rejected状态的promise对象 来实现的，这种方法不通过使用 throw 就能在promise chain中对 onRejected 进行调用。

关于这种方法由于和本小节关系不大就不在这里详述了，大家可以参考一下第4章 使用reject而不是throw 中的内容。

此外在promise chain中，由于在 onRejected 和 Final Task 后面没有 catch 处理了，因此在这两个Task中如果出现异常的话将不会被捕获，这点需要注意一下。

下面我们再来看一个具体的关于 Task A → onRejected 的例子。

前面例子中的Task都是相互独立的，只是被简单调用而已。

这时候如果 Task A 想给 Task B 传递一个参数该怎么办呢？

答案非常简单，那就是在 Task A 中 return 的返回值，会在 Task B 执行时传给它。

我们还是先来看一个具体例子吧。

这段代码的入口函数是 Promise.resolve(1); ，整体的promise chain执行流程如下所示。

每个方法中 return 的值不仅只局限于字符串或者数值类型，也可以是对象或者promise对象等复杂类型。

return的值会由 Promise.resolve(return的返回值); 进行相应的包装处理，因此不管回调函数中会返回一个什么样的值，最终 then 的结果都是返回一个新创建的promise对象。

也就是说， Promise#then 不仅仅是注册一个回调函数那么简单，它还会将回调函数的返回值进行变换，创建并返回一个promise对象。

上面的这张图，是下面这段代码在使用 polyfill 的情况下在个浏览器上执行的结果。

如果我们在各种浏览器中执行这段代码，那么在IE8及以下版本则会出现 identifier not found 的语法错误。

这是怎么回事呢？ 实际上这和 catch 是ECMAScript的 保留字 (Reserved Word)有关。

在ECMAScript 3中保留字是不能作为对象的属性名使用的。 而IE8及以下版本都是基于ECMAScript 3实现的，因此不能将 catch 作为属性来使用，也就不能编写类似 promise.catch() 的代码，因此就出现了 identifier not found 这种语法错误了。

而现在的浏览器都是基于ECMAScript 5的，而在ECMAScript 5中保留字都属于 IdentifierName ，也可以作为属性名使用了。

当然，我们也可以想办法回避这个ECMAScript 3保留字带来的问题。

点标记法（dot notation） 要求对象的属性必须是有效的标识符（在ECMAScript 3中则不能使用保留字），

但是使用 中括号标记法（bracket notation）的话，则可以将非合法标识符作为对象的属性名使用。

也就是说，上面的代码如果像下面这样重写的话，就能在IE8及以下版本的浏览器中运行了（当然还需要polyfill）。

或者我们不单纯的使用 catch ，而是使用 then 也是可以避免这个问题的。

由于 catch 标识符可能会导致问题出现，因此一些类库（Library）也采用了 caught 作为函数名，而函数要完成的工作是一样的。

而且很多压缩工具自带了将 promise.catch 转换为 promise["catch"] 的功能， 所以可能不经意之间也能帮我们解决这个问题。

如果各位读者需要支持IE8及以下版本的浏览器的话，那么一定要将这个 catch 问题牢记在心中。

这段回调函数风格的代码有以下几个要点。

在使用 jsonParse 函数的时候我们使用了 bind 进行绑定，通过使用这种偏函数（Partial Function）的方式就可以减少匿名函数的使用。（如果在函数回调风格的代码能很好的做到函数分离的话，也能减少匿名函数的数量）

在这段回调风格的代码中，我们也能发现如下一些问题。

下面我们再来看看如何使用 Promise#then 来完成同样的工作。

需要事先说明的是 Promise.all 比较适合这种应用场景的需求，因此我们故意采用了大量 .then 的晦涩的写法。

使用了.then 的话，也并不是说能和回调风格完全一致，大概重写后代码如下所示。

将上述代码和回调函数风格相比，我们可以得到如下结论。

向前面我们说的那样，main的 then 部分有点晦涩难懂。

为了应对这种需要对多个异步调用进行统一处理的场景，Promise准备了 Promise.all 和 Promise.race 这两个静态方法。

在下面的小节中我们将对这两个函数进行说明。

我们看看下面的这段代码。

在上面的代码中， badMain 是一个不太好的实现方式（但也不是说它有多坏）， goodMain 则是一个能非常好的进行错误处理的版本。

为什么说 badMain 不好呢？，因为虽然我们在 .then 的第二个参数中指定了用来错误处理的函数，但实际上它却不能捕获第一个参数 onFulfilled 指定的函数（本例为 throwError ）里面出现的错误。

也就是说，这时候即使 throwError 抛出了异常，onRejected 指定的函数也不会被调用（即不会输出"BAD"字样）。

与此相对的是， goodMain 的代码则遵循了 throwError→onRejected 的调用流程。 这时候 throwError 中出现异常的话，在会被方法链中的下一个方法，即 .catch 所捕获，进行相应的错误处理。

.then 方法中的onRejected参数所指定的回调函数，实际上针对的是其promise对象或者之前的promise对象，而不是针对 .then 方法里面指定的第一个参数，即onFulfilled所指向的对象，这也是 then 和 catch 表现不同的原因。

这种情况下 then 是针对 Promise.resolve(42) 的处理，在onFulfilled 中发生异常，在同一个 then 方法中指定的 onRejected 也不能捕获该异常。

在这个 then 中发生的异常，只有在该方法链后面出现的 catch 方法才能捕获。

当然，由于 .catch 方法是 .then 的别名，我们使用 .then 也能完成同样的工作。只不过使用 .catch 的话意图更明确，更容易理解。

这里我们又学习到了如下一些内容。

我们需要注意如果代码类似 badMain 那样的话，就可能出现程序不会按预期运行的情况，从而不能正确的进行错误处理。

Mocha是Node.js下的测试框架工具,在这里，我们并不打算对 Mocha本身进行详细讲解。对 Mocha感兴趣的读者可以自行学习。

Mocha可以自由选择BDD、TDD、exports中的任意风格，测试中用到的Assert 方法也同样可以跟任何其他类库组合使用。 也就是说，Mocha本身只提供执行测试时的框架，而其他部分则由使用者自己选择。

这里我们选择使用Mocha，主要基于下面3点理由。

最后至于为什么说 支持"Promise测试" ，这个我们在后面再讲。

要想在本章中使用Mocha，我们需要先通过npm来安装Mocha。

另外，Assert库我们使用的是Node.js自带的assert模块，所以不需要额外安装。

首先，让我们试着编写一个对传统回调风格的异步函数进行测试的代码。

如果想使用回调函数风格来对一个异步处理进行测试，使用Mocha的话代码如下所示。

将这段代码保存为 basic-test.js，之后就可以使用刚才安装的Mocha的命令行工具进行测试了。

Mocha的 it 方法指定了 done 参数，在 done() 函数被执行之前， 该测试一直处于等待状态，这样就可以对异步处理进行测试。

Mocha中的异步测试，将会按照下面的步骤执行。

这也是一种非常常见的实现方式。

接下来，让我们看看如何使用 done 来进行Promise测试。

Promise.resolve 用来返回promise对象， 返回的promise对象状态为FulFilled。 最后，通过 .then 设置的回调函数也会被调用。

像专栏: Promise只能进行异步操作？ 中已经提到的那样， promise对象的调用总是异步进行的，所以测试也同样需要以异步调用的方式来编写。

但是，在前面的测试代码中，在assert 失败的情况下就会出现问题。

在此次测试中 assert 失败了，所以你可能认为应该抛出“测试失败”的错误， 而实际情况却是测试并不会结束，直到超时。

通常情况下，assert 失败的时候，会throw一个error， 测试框架会捕获该error，来判断测试失败。

但是，Promise的情况下 .then 绑定的函数执行时发生的error 会被Promise捕获，而测试框架则对此error将会一无所知。

我们来改善一下assert 失败的promise测试， 让它能正确处理 assert 失败时的测试结果。

在上面测试正常失败的示例中，为了确保 done 一定会被调用， 我们在最后添加了 .then(done, done); 语句。

assert 测试通过（成功）时会调用 done() ，而 assert 失败时则调用 done(error) 。

这样，我们就编写出了和 回调函数风格的测试 相同的Promise测试。

但是，为了处理 assert 失败的情况，我们需要额外添加 .then(done, done); 的代码。 这就要求我们在编写Promise测试时要格外小心，忘了加上上面语句的话，很可能就会写出一个永远不会返回直到超时的测试代码。

在下一节，让我们接着学习一下最初提到的使用Mocha理由中的支持"Promises测试"究竟是一种什么机制。

因为Mocha提供了对Promise的测试，所以我们会认为按照Mocha的规则来写会比较好。 但是这种代码可能会带来意想不到的异常情况的发生。

比如对下面的mayBeRejected() 函数的测试代码，该函数返回一个当满足某一条件就变为Rejected的promise对象。

这个测试的目的包括以下两点：

上面的测试代码，当promise对象变为Rejected的时候，会调用在 onRejected 中注册的函数，从而没有走正promise的处理常流程，测试会成功。

这段测试代码的问题在于当mayBeRejected() 返回的是一个 为FulFilled状态的promise对象时，测试会一直成功。

在这种情况下，由于在 catch 中注册的 onRejected 函数并不会被调用，因此 assert 也不会被执行，测试会一直通过（passed，成功）。

为了解决这个问题，我们可以在 .catch 的前面加入一个 .then 调用，可以理解为如果调用了 .then 的话，那么测试就需要失败。

但是，这种写法会像在前面 then or catch? 中已经介绍的一样， failTest 抛出的异常会被 catch 捕获。

程序的执行流程为 then → catch，传递给 catch 的Error对象为AssertionError类型 ， 这并不是我们想要的东西。

也就是说，我们希望测试只能通过状态会变为onRejected的promise对象， 如果promise对象状态为onFulfilled状态的话，那么该测试就会一直通过。

在编写 上面对Error对象进行测试的例子 时， 怎么才能剔除那些会意外通过测试的情况呢？

最简单的方式就是像下面这样，在测试代码中判断在各种promise对象的状态下，应进行如何的操作。

也就是说，我们需要在测试代码中明确指定在Fulfilled和Rejected这两种状态下，都需进行什么样的处理。

像这样的话，就能在promise变为FulFilled的时候编写出失败用的测试代码了。

在 then or catch? 中我们已经讲过，为了避免遗漏对错误的处理， 与使用 .then(onFulfilled, onRejected) 这样带有二个参数的调用形式相比， 我们更推荐使用 then → catch 这样的处理方式。

但是在编写测试代码的时候，Promise强大的错误处理机制反而成了限制我们的障碍。 因此我们不得已采取了 .then(failTest, onRejected) 这种写法，明确指定promise在各种状态下进行何种的处理。

在本小节中我们对在使用Mocha进行Promise测试时可能出现的一些意外情况进行了介绍。

通过使用 .then(onFulfilled, onRejected) 这种形式的写法， 我们可以明确指定promise对象在变为 Fulfilled或Rejected时如何进行处理。

但是，由于需要显示的指定 Rejected时的测试处理， 像下面这样的代码看起来总是有一些让人感到不太直观的感觉。

在下一小节，我们会介绍如何编写helper函数以方便编写Promise的测试代码， 以及怎样去编写更容易理解的测试代码。

为了编写有效的测试代码， 我们需要明确指定 promise的状态 为 Fulfilled or Rejected 的两者之一。

但是由于 .then 的话在调用的时候可以省略参数，有时候可能会忘记加入使测试失败的条件。

因此，我们可以定义一个helper函数，用来明确定义promise期望的状态。

首先我们创建一个名为 shouldRejected 的helper函数，用来在刚才的 .then 的例子中，期待测试返回状态为 onRejected 的结果的例子。

shouldRejected 函数接收一个promise对象作为参数，并且返回一个带有 catch 方法的对象。

在这个 catch 中可以使用和 onRejected 里一样的代码，因此我们可以在 catch 使用基于 assertion 方法的测试代码。

在 shouldRejected 外部，都是类似如下、和普通的promise处理大同小异的代码。

在使用 shouldRejected 函数的时候，如果是 Fulfilled 被调用了的话，则会throw一个异常，测试也会失败。

使用 shouldRejected 这样的helper函数，测试代码也会变得很直观。

像上面一样，我们也可以编写一个测试promise对象期待结果为Fulfilled的 shouldFulfilled helper函数。

这和上面的 shouldRejected-test.js 结构基本相同，只不过返回对象的 catch 方法变为了 then ，promise.then的两个参数也调换了。

在本小节我们学习了如何编写针对Promise特定状态的测试代码，以及如何使用便于测试的helper函数。

此外，本小节中的helper方法都是以 Mocha对Promise的支持 为前提的， 在 基于done 的测试 中使用的话可能会比较麻烦。

是使用基于测试框架对Promis的支持，还是使用基于类似done 这样回调风格的测试方式，每个人都可以自由的选择，只是风格问题，我觉得倒没必要去争一个孰优孰劣。

比如在 CoffeeScript下进行测试的话，由于CoffeeScript 会隐式的使用return返回，所以使用 done 的话可能更容易理解一些。

对Promise进行测试比对通常的异步函数进行测试坑更多，虽说采取什么样的测试方法是个人的自由，但是在同一项目中采取前后风格一致的测试则是非常重要。

为什么需要这些类库呢？我想有些读者不免会有此疑问。首先能想到的原因是有些运行环境并不支持 ES6 Promises 。

当我们在网上查找Promise的实现类库的时候，有一个因素是首先要考虑的，那就是是否具有 Promises/A+兼容性 。

Promises/A+ 是 ES6 Promises 的前身，Promise的 then 也是来自于此的基于社区的规范。

如果说一个类库兼容 Promises/A+ 的话，那么就是说它除了具有标准的 then 方法之外，很多情况下也说明此类库还支持 Promise.all 和 catch 等功能。

但是 Promises/A+ 实际上只是定义了关于 Promise#then 的规范，所以有些类库可能实现了其它诸如 all 或 catch 等功能，但是可能名字却不一样。

如果我们说一个类库具有 then 兼容性的话，实际上指的是 Thenable ，它通过使用 Promise.resolve 基于ES6 Promise的规定，进行promise对象的变换。

在这些Promise的实现类库中，我们这里主要对两种类型的类库进行介绍。

一种是被称为 Polyfill （这是一款英国产品，就是装修刮墙用的腻子，其意义可想而知 — 译者注）的类库，另一种是即具有 Promises/A+兼容性 ，又增加了自己独特功能的类库。

本小节介绍了Promise的实现类库中的 Polyfill 和扩展类库这两种。

Promise的实现类库种类繁多，到底选择哪个来使用完全看自己的喜好了。

但是由于这些类库实现的 Promise 同时具有 Promises/A+ 或 ES6 Promises 共通的接口，所以在使用某一类库的时候，有时候也可以参考一下其他类库的代码或者扩展功能。

熟练掌握Promise中的共通概念，进而能在实际中能对这些技术运用自如，这也是本书的写作目的之一。

这里我们以桌面通知 API Web Notifications 为例进行说明。

关于Web Notifications API的详细信息可以参考下面的网址。

简单来说，Web Notifications API就是能像以下代码那样通过 new Notification 来显示通知消息。

当然，为了显示通知消息，我们需要在运行 new Notification 之前，先获得用户的许可。

用户在这个是否允许Notification的对话框选择后的结果，会通过 Notification.permission 传给我们的程序，它的值可能是允许("granted")或拒绝("denied")这二者之一。

在程序中可以通过 Notification.requestPermission() 来弹出是否允许Notification对话框， 用户选择的结果会通过 status 参数传给回调函数。

从这个回调函数我们也可以看出来，用户选择允许还是拒绝通知是异步进行的。

到用户收到并显示通知为止，整体的处理流程如下所示。

虽然上面说到了几种情景，但是最终结果就是用户允许或者拒绝，可以总结为如下两种模式。

这两种模式是不是觉得有在哪里看过的感觉？ 呵呵，用户的选择结果，正和在Promise中promise对象变为 Fulfilled 或 Rejected 状态非常类似。

是不是我们可以用Promise的方式去编写桌面通知的代码呢？我们先从回调函数风格的代码入手看看到底怎么去做。

首先，我们以回到函数风格的代码对上面的Web Notification API包装函数进行重写，新代码如下所示。

在回调风格的代码里，当用户拒绝接收通知的时候， error 会被设置值，而如果用户同意接收通知的时候，则会显示通知消息并且 notification 会被设置值。

下面，我想再将这个回调函数风格的代码使用Promise进行改写。

基于上述回调风格的 notifyMessage 函数，我们再来创建一个返回promise对象的 notifyMessageAsPromise 方法。

在用户允许接收通知的时候，运行上面的代码，会显示 "Hi!" 消息。

当用户接收通知消息的时候， .then 函数会被调用，当用户拒绝接收消息的时候， .catch 方法会被调用。

上面的 notification-as-promise.js 虽然看上去很方便，但是实际上使用的时候，很可能出现 在不支持Promise的环境下不能使用 的问题。

如果你想编写像notification-as-promise.js这样具有Promise风格和的类库的话，我觉得你有如下的一些选择。

notification-as-promise.js就是以Promise存在为前提的写法。

回归正文，在这里Thenable是为了帮助实现在回调函数中也能使用Promise的一个概念。

我们已经说过，thenable就是一个具有 .then方法的一个对象。下面我们就在notification-callback.js中增加一个返回值为 thenable 类型的方法。

notification-thenable.js里增加了一个 notifyMessageAsThenable方法。这个方法返回的对象具备一个then方法。

then方法的参数和 new Promise(function (resolve, reject){}) 一样，在确定时执行 resolve 方法，拒绝时调用 reject 方法。

then 方法和 notification-as-promise.js 中的 notifyMessageAsPromise 方法完成了同样的工作。

我们可以看出， Promise.resolve(thenable) 通过使用了 thenable 这个promise对象，就能利用Promise功能了。

使用了Thenable的notification-thenable.js 和依赖于Promise的 notification-as-promise.js ，实际上都是非常相似的使用方法。

notification-thenable.js 和 notification-as-promise.js比起来，有以下的不同点。

通过使用Thenable对象，我们可以实现类似已有的回调式风格和Promise风格中间的一种实现风格。

在本小节我们主要学习了什么是Thenable，以及如何通过Promise.resolve(thenable) 使用Thenable，将其作为promise对象来使用。

Callback — Thenable — Promise

Thenable风格表现为位于回调和Promise风格中间的一种状态，作为类库的公开API有点不太成熟，所以并不常见。

Thenable本身并不依赖于Promise功能，但是Promise之外也没有使用Thenable的方式，所以可以认为Thenable间接依赖于Promise。

另外，用户需要对 Promise.resolve(thenable) 有所理解才能使用好Thenable，因此作为类库的公开API有一部分会比较难。和公开API相比，更多情况下是在内部使用Thenable。

话说回来，为什么在想将promise对象的状态设置为Rejected的时候应该使用 reject 而不是 throw 呢？

首先是因为我们很难区分 throw 是我们主动抛出来的，还是因为真正的其它 异常 导致的。

比如在使用Chrome浏览器的时候，Chrome的开发者工具提供了在程序发生异常的时候自动在调试器中break的功能。

当我们开启这个功能的时候，在执行到下面代码中的 throw 时就会触发调试器的break行为。

本来这是和调试没有关系的地方，也因为在Promise中的 throw 语句被break了，这也严重的影响了浏览器提供的此功能的正常使用。

在Promise构造函数中，有一个用来指定 reject 方法的参数，使用这个参数而不是依靠 throw 将promise对象的状态设置为Rejected状态非常简单。

那么如果像下面那样想在 then 中进行reject的话该怎么办呢？

上面的超时处理，需要在 then 中进行 reject 方法调用，但是传递给当前的回调函数的参数只有前面的一promise对象，这该怎么办呢？

在这里我们再次回忆下 then 的工作原理。

在 then 中注册的回调函数可以通过 return 返回一个值，这个返回值会传给后面的 then 或 catch 中的回调函数。

而且return的返回值类型不光是简单的字面值，还可以是复杂的对象类型，比如promise对象等。

这时候，如果返回的是promise对象的话，那么根据这个promise对象的状态，在下一个 then 中注册的回调函数中的onFulfilled和onRejected的哪一个会被调用也是能确定的。

也就是说，这个 retPromise 对象状态为Rejected的时候，会调用后面then中的 onRejected 方法，这样就实现了即使在 then 中不使用 throw 也能进行reject处理了。

使用 Promise.reject 的话还能再将代码进行简化。

在本小节我们主要学习了

也许实际中我们可能不常使用 reject ，但是比起来不假思索的使用 throw 来说，使用 reject 的好处还是很多的。

关于上面讲的内容的比较详细的例子，大家可以参考在 使用Promise.race和delay取消XHR请求 小节的介绍。

说起Promise，我想大家一定同时也听说过Deferred这个术语。比如 jQuery.Deferred 和 JSDeferred 等，一定都是大家非常熟悉的内容了。

Deferred和Promise不同，它没有共通的规范，每个Library都是根据自己的喜好来实现的。

在这里，我们打算以 jQuery.Deferred 类似的实现为中心进行介绍。

简单来说，Deferred和Promise具有如下的关系。

我想各位看到此图应该就很容易理解了，Deferred和Promise并不是处于竞争的关系，而是Deferred内涵了Promise。

光看图的话也许还难以理解，下面我们就看看看怎么通过Promise来实现Deferred。

基于Promise实现Deferred的例子。

我们再将之前使用Promise实现的 getURL 用Deferred改写一下。

所谓的能对Promise状态进行操作的特权方法，指的就是能对promise对象的状态进行resolve、reject等调用的方法，而通常的Promise的话只能在通过构造函数传递的方法之内对promise对象的状态进行操作。

我们来看看Deferred和Promise相比在实现上有什么异同。

对比上述两个版本的 getURL ，我们发现它们有如下不同。

在以下方面，它们则完成了同样的工作。

由于Deferred包含了Promise，所以大体的流程还是差不多的，不过Deferred有用对Promise进行操作的特权方法，以及高度自由的对流程控制进行自由定制。

比如在Promise一般都会在构造函数中编写主要处理逻辑，对 resolve、reject 方法的调用时机也基本是很确定的。

而使用Deferred的话，并不需要将处理逻辑写成一大块代码，只需要先创建deferred对象，可以在任何时机对 resolve、reject 方法进行调用。

上面我们只是简单的实现了一个 Deferred ，我想你已经看到了它和 Promise 之间的差异了吧。

如果说Promise是用来对值进行抽象的话，Deferred则是对处理还没有结束的状态或操作进行抽象化的对象，我们也可以从这一层的区别来理解一下这两者之间的差异。

换句话说，Promise代表了一个对象，这个对象的状态现在还不确定，但是未来一个时间点它的状态要么变为正常值（FulFilled），要么变为异常值（Rejected）；而Deferred对象表示了一个处理还没有结束的这种事实，在它的处理结束的时候，可以通过Promise来取得处理结果。

如果各位读者还想深入了解一下Deferred的话，可以参考下面的这些资料。

首先我们来看一下如何在Promise中实现超时。

所谓超时就是要在经过一定时间后进行某些操作，使用 setTimeout 的话很好理解。

首先我们来串讲一个单纯的在Promise中调用 setTimeout 的函数。

delayPromise(ms) 返回一个在经过了参数指定的毫秒数后进行onFulfilled操作的promise对象，这和直接使用 setTimeout 函数比较起来只是编码上略有不同，如下所示。

在这里 promise对象 这个概念非常重要，请切记。

让我们回顾一下静态方法 Promise.race ，它的作用是在任何一个promise对象进入到确定（解决）状态后就继续进行后续处理，如下面的例子所示。

我们可以将刚才的 delayPromise 和其它promise对象一起放到 Promise.race 中来是实现简单的超时机制。

函数 timeoutPromise(比较对象promise, ms) 接收两个参数，第一个是需要使用超时机制的promise对象，第二个参数是超时时间，它返回一个由 Promise.race 创建的相互竞争的promise对象。

之后我们就可以使用 timeoutPromise 编写下面这样的具有超时机制的代码了。

虽然在发生超时的时候抛出了异常，但是这样的话我们就不能区分这个异常到底是普通的错误还是超时错误了。

为了能区分这个 Error 对象的类型，我们再来定义一个Error 对象的子类 TimeoutError。

Error 对象是ECMAScript的内建（build in）对象。

但是由于stack trace等原因我们不能完美的创建一个继承自 Error 的类，不过在这里我们的目的只是为了和Error有所区别，我们将创建一个 TimeoutError 类来实现我们的目的。

为了让我们的 TimeoutError 能支持类似 error instanceof TimeoutError 的使用方法，我们还需要进行如下工作。

我们定义了 TimeoutError 类和构造函数，这个类继承了Error的prototype。

它的使用方法和普通的 Error 对象一样，使用 throw 语句即可，如下所示。

有了这个 TimeoutError 对象，我们就能很容易区分捕获的到底是因为超时而导致的错误，还是其他原因导致的Error对象了。

到这里，我想各位读者都已经对如何使用Promise来取消一个XHR请求都有一些思路了吧。

取消XHR操作本身的话并不难，只需要调用 XMLHttpRequest 对象的 abort() 方法就可以了。

为了能在外部调用 abort() 方法，我们先对之前本节出现的 getURL 进行简单的扩展，cancelableXHR 方法除了返回一个包装了XHR的promise对象之外，还返回了一个用于取消该XHR请求的abort方法。

在这些问题都明了之后，剩下只需要进行Promise处理的流程进行编码即可。大体的流程就像下面这样。

将上面的步骤总结一下的话，代码如下所示。

上面的代码就通过在一定的时间内变为解决状态的promise对象实现了超时处理。

在前面的 cancelableXHR 中，promise对象及其操作方法都是在一个对象中返回的，看起来稍微有些不太好理解。

从代码组织的角度来说一个函数只返回一个值（promise对象）是一个非常好的习惯，但是由于在外面不能访问 cancelableXHR 方法中创建的 req 变量，所以我们需要编写一个专门的函数（上面的例子中的abort）来对这些内部对象进行处理。

当然也可以考虑到对返回的promise对象进行扩展，使其支持abort方法，但是由于promise对象是对值进行抽象化的对象，如果不加限制的增加操作用的方法的话，会使整体变得非常复杂。

大家都知道一个函数做太多的工作都不认为是一个好的习惯，因此我们不会让一个函数完成所有功能，也许像下面这样对函数进行分割是一个不错的选择。

将这些处理整理为一个模块的话，以后扩展起来也方便，一个函数所做的工作也会比较精炼，代码也会更容易阅读和维护。

我们有很多方法来创建一个模块（AMD,CommonJS,ES6 module etc..），在这里，我们将会把前面的 cancelableXHR 整理为一个Node.js的模块使用。

使用方法也非常简单，我们通过 createXHRPromise 方法得到XHR的promise对象，当想对这个XHR进行abort操作的时候，将这个promise对象传递给 abortPromise(promise) 方法就可以了。

在这里我们学到了如下内容。

Promise能非常灵活的进行处理流程的控制，为了充分发挥它的能力，我们需要注意不要将一个函数写的过于庞大冗长，而是应该将其分割成更小更简单的处理，并对之前JavaScript中提到的机制进行更深入的了解。

看一下实际使用done的代码的例子的话，应该就非常容易理解 done 方法的行为了。

在前面我们已经说过，promise设计规格并没有对 Promise.prototype.done做出任何规定，因此在使用的时候，你可以使用已有类库提供的实现，也可以自己去实现。

我们会在后面讲述如何去自己实现，首先我们这里先对使用 then 和使用 done这两种方式进行一下比较。

从上面我们可以看出，两者之间有以下不同点。

由于done 不会返回promise对象，所以我们不难理解它只能出现在一个方法链的最后。

此外，我们已经介绍过了Promise具有强大的错误处理机制，而done则会在函数中跳过错误处理，直接抛出异常。

为什么很多类库都提供了这个和Promise功能相矛盾的函数呢？看一下下面Promise处理失败的例子，也许我们多少就能理解其中原因了吧。

Promise虽然具备了强大的错误处理机制，但是（调试工具不能顺利运行的时候）这个功能会导致人为错误（human error）更加复杂，这也是它的一个缺点。

也许你还记得，我们在 then or catch? 中也看到了类似的内容。

像下面那样，我们看一个能返回promise对象的函数。

这个函数将接收到的参数传递给 JSON.parse ，并返回一个基于JSON.parse的promise对象。

我们可以像下面那样使用这个Promise函数，由于 JSON.parse 会解析失败并抛出一个异常，该异常会被 catch 捕获。

如果这个解析失败的异常被正常捕获的话则没什么问题，但是如果编码时忘记了处理该异常，一旦出现异常，那么查找异常发生的源头将会变得非常棘手，这就是使用promise需要注意的一面。

如果是JSON.parse 这样比较好找的例子还算好说，如果是拼写错误的话，那么发生了Syntax Error错误的话将会非常麻烦。

这这个例子里，我们错把 console 拼成了 conosle ，因此会发生如下错误。

但是，由于Promise的try-catch机制，这个问题可能会被内部消化掉。 如果在调用的时候每次都无遗漏的进行 catch 处理的话当然最好了，但是如果在实现的过程中出现了这个例子中的错误的话，那么进行错误排除的工作也会变得困难。

这种错误被内部消化的问题也被称为 unhandled rejection ，从字面上看就是在Rejected时没有找到相应处理的意思。

作为方法论，在Promise中 done 是怎么解决上面提到的错误被忽略呢？ 其实它的方法很简单直接，那就是必须要进行错误处理。

由于可以在 Promise上实现 done 方法，因此我们看看如何对 Promise.prototype.done 这个Promise的prototype进行扩展。

那么它是如何将异常抛到Promise的外面的呢？其实这里我们利用的是在setTimeout中使用throw方法，直接将异常抛给了外部。

仔细看一下 Promise.prototype.done的代码，我们会发现这个函数什么也没 return 。 也就是说， done按照「Promise chain在这里将会中断，如果出现了异常，直接抛到promise外面即可」的原则进行了处理。

如果实现和运行环境实现的比较完美的话，就可以进行 unhandled rejection 检测，done也不一定是必须的了。 另外像本小节中的 Promise.prototype.done一样，done也可以在既有的Promise之上进行实现，也可以说它没有进入到 ES6 Promises的设计规范之中。

在本小节中，我们学习了 Q 、 Bluebird 和 prfun 等Promise类库提供的 done 的基础和实现细节，以及done方法和 then 方法有什么区别等内容。

我们也学到了 done 有以下两个特点。

和 then or catch? 中说到的一样，由Promise内部消化掉的错误，随着调试工具或者类库的改进，大多数情况下也许已经不是特别大的问题了。

此外，由于 done 不会有返回值，因此不能在它之后进行方法链的创建，为了实现Promise方法风格上的统一，我们也可以使用done方法。

ES6 Promises 本身提供的功能并不是特别多。 因此，我想很多时候可能需要我们自己进行扩展或者使用第三方类库。

我们好不容易将异步处理统一采用Promise进行统一处理，但是如果做过头了，也会将系统变得特别复杂，因此，保持风格的统一是Promise作为抽象对象非常重要的部分。

我们下面将会以 Node.js中的fs 为例进行说明。

此外，这里的例子我们更重视代码的易理解性，因此从实际上来说这个例子可能并不算太实用。

这个模块可以将类似下面的 read → transform → write 这一系列处理，通过组成一个方法链来实现。

transform 接收一个方法作为参数，该方法对其输入参数进行处理。在这个例子里，我们对通过read读取的数据在前面加上了 >> 字符串。

下面我们就在不改变刚才的方法链对外接口的前提下，采用Promise对内部实现进行重写。

新增加的then 和catch都可以看做是指向内部保存的promise对象的别名，而其它部分从对外接口的角度来说都没有改变，使用方法也和原来一样。

因此，在使用这个模块的时候我们只需要修改 require 的模块名即可。

File.prototype.then 方法会调用 this.promise.then 方法，并将返回的promise对象赋值给了 this.promise 变量这个内部promise对象。

这究竟有什么奥妙么？通过以下的伪代码，我们可以更容易理解这背后发生的事情。

看到 promise = promise.then(...) 这种写法，会让人以为promise的值会被覆盖，也许你会想是不是promise的chain被截断了。

你可以想象为类似 promise = addPromiseChain(promise, fn); 这样的感觉，我们为promise对象增加了新的处理，并返回了这个对象，因此即使自己不实现顺序处理的话也不会带来什么问题。

如果你很熟悉Node.js的話，那么看到方法链的话，你是不是会想起来 Stream 呢。

如果使用 Stream 的话，就可以免去了保存 this.lastValue 的麻烦，还能改善处理大文件时候的性能。 另外，使用Stream的话可能会比使用Promise在处理速度上会快些。

因此，在异步处理的时候并不是说Promise永远都是最好的选择，要根据自己的目的和实际情况选择合适的实现方式。

关于Node.js中Stream的详细信息可以参考以下网页。

再回到 fs-method-chain.js 和 Promise版，这两种方法相比较内部实现也非常相近，让人觉得是不是同步版本的代码可以直接就当做异步方式来使用呢？

由于JavaScript可以向对象动态添加方法，所以从理论上来说应该可以从非Promise版自动生成Promise版的代码。（当然静态定义的实现方式容易处理）

尽管 ES6 Promises 并没有提供此功能，但是著名的第三方Promise实现类库 bluebird 等提供了被称为 Promisification 的功能。

如果使用类似这样的类库，那么就可以动态给对象增加promise版的方法。

在本小节我们主要学习了下面的这些内容。

ES6 Promises只提供了一些Core级别的功能。 因此，我们也许需要对现有的方法用Promise方式重新包装一下。

但是，类似Event等调用次数没有限制的回调函数等在并不适合使用Promise，Promise也不能说什么时候都是最好的选择。

至于什么情况下应该使用Promise，什么时候不该使用Promise，并不是本书要讨论的目的， 我们需要牢记的是不要什么都用Promise去实现，我想最好根据自己的具体目的和情况，来考虑是应该使用Promise还是其它方法。

在 重复使用多个then的方法 中的实现方法如下。

使用这种写法的话那么随着 request 中元素数量的增加，我们也需要不断增加对 then 方法的调用

因此，如果我们将处理内容统一放到数组里，再配合for循环进行处理的话，那么处理内容的增加将不会再带来什么问题。首先我们就使用for循环来完成和前面同样的处理。

使用for循环的时候，如同我们在 专栏: 每次调用then都会返回一个新创建的promise对象 以及 Promise和方法链 中学到的那样，每次调用 Promise#then 方法都会返回一个新的promise对象。

因此类似 promise = promise.then(task).then(pushValue); 的代码就是通过不断对promise进行处理，不断的覆盖 promise 变量的值，以达到对promise对象的累积处理效果。

但是这种方法需要 promise 这个临时变量，从代码质量上来说显得不那么简洁。

如果将这种循环写法改用 Array.prototype.reduce 的话，那么代码就会变得聪明多了。

如果将上面的代码用 Array.prototype.reduce 重写的话，会像下面一样。

这段代码中除了 main 函数之外的其他处理都和使用for循环的时候相同。

Array.prototype.reduce 的第二个参数用来设置盛放计算结果的初始值。在这个例子中， Promise.resolve() 会赋值给 promise ，此时的 task 为 request.comment 。

在reduce中第一个参数中被 return 的值，则会被赋值为下次循环时的 promise 。也就是说，通过返回由 then 创建的新的promise对象，就实现了和for循环类似的 Promise chain 了。

使用reduce和for循环不同的地方是reduce不再需要临时变量 promise 了，因此也不用编写 promise = promise.then(task).then(pushValue); 这样冗长的代码了，这是非常大的进步。

虽然 Array.prototype.reduce 非常适合用来在Promise中进行顺序处理，但是上面的代码有可能让人难以理解它是如何工作的。

因此我们再来编写一个名为 sequenceTasks 的函数，它接收一个数组作为参数，数组里面存放的是要进行的处理Task。

从下面的调用代码中我们可以非常容易的从其函数名想到，该函数的功能是对 tasks 中的处理进行顺序执行了。

基本上我们只需要基于 使用reduce的方法 重构出一个函数。

需要注意的一点是，和 Promise.all 等不同，这个函数接收的参数是一个函数的数组。

为什么传给这个函数的不是一个promise对象的数组呢？这是因为promise对象创建的时候，XHR已经开始执行了，因此再对这些promise对象进行顺序处理的话就不能正常工作了。

因此 sequenceTasks 将函数(该函数返回一个promise对象)的数组作为参数。

最后，使用 sequenceTasks 重写最开始的例子的话，如下所示。

怎样， main() 中的流程是不是更清晰易懂了。

如上所述，在Promise中，我们可以选择多种方法来实现处理的按顺序执行。

但是，这些方法都是基于JavaScript中对数组及进行操作的for循环或 forEach 等，本质上并无大区别。 因此从一定程度上来说，在处理Promise的时候，将大块的处理分成小函数来实现是一个非常好的实践。

在本小节中，我们对如何在Promise中进行和 Promise.all 相反，按顺序让promise一个个进行处理的实现方式进行了介绍。

为了实现顺序处理，我们也对从过程风格的编码方式到自定义顺序处理函数的方式等实现方式进行了介绍，也再次强调了在Promise领域我们应遵循将处理按照函数进行划分的基本原则。

在Promise中如果还使用了Promise chain将多个处理连接起来的话，那么还可能使源代码中的一条语句变得很长。

这时候如果我们回想一下这些编程的基本原则进行函数拆分的话，代码整体结构会变得非常清晰。

此外,Promise的构造函数以及 then 都是高阶函数，如果将处理分割为函数的话，还能得到对函数进行灵活组合使用的副作用，意识到这一点对我们也会有一些帮助的。